--- title: "Laudo Oficial de Correção — Prova Teórica 1" subtitle: "Gestão de Projetos de Software (GPS) • CEFET-MG 2026.2" author: "Prof. Aléssio Miranda Júnior" date: "2026-10-19" discente: "Sabrina Evelyn Siqueira" matricula: "20243000454" nota_final: "12,7" nota_maxima: "25,0" aproveitamento: "50,8%" legibilidade: "95% (Alta)" format: html: toc: true theme: cosmo pdf: documentclass: scrartcl papersize: a4 geometry: - margin=20mm colorlinks: true --- ::: {.callout-note appearance="simple"} ## Dados do Discente - **Discente:** Sabrina Evelyn Siqueira - **Matrícula:** `20243000454` - **Data da Avaliação:** 19/10/2026 - **Pontuação Final:** **12,7 / 25,0** (Aproveitamento: **50,8%**) - **Legibilidade da Caligrafia:** 95% (Alta) ::: ## Desempenho Consolidado por Questão | Questão / Tema | Pontos Obtidos | Valor | Aproveitamento | |:---|:---:|:---:|:---:| | **Q1:** Projeto, Ciclo de Vida e Trade-offs | **2,3** | 5,0 | 46,0% | | **Q2:** Escopo, EAP e Backlog | **2,8** | 5,0 | 56,0% | | **Q3:** Qualidade, CoQ e Definição de Pronto | **2,3** | 5,0 | 46,0% | | **Q4:** Riscos, Segurança de IA e Documentação | **3,1** | 5,0 | 62,0% | | **Q5:** Comunicação, Stakeholders e Conflitos | **2,2** | 5,0 | 44,0% | | **TOTAL GERAL** | **12,7** | **25,0** | **50,8%** | --- ## Questão 1 — Projeto, Ciclo de Vida e Trade-offs (2,3 / 5,0 pts) ### 1.1 Classificação como Projeto vs. Operação e Evidências (0,8 / 1,5) ::: {.callout-note icon=false title="Resposta Transcrita do Aluno"} > "O Professor Agente é um projeto, isso é evidenciado na execução descrita, onde existem características de desempenho esperado (tempo de resposta), conexão com a API e a sprint" ::: ::: {.callout-tip icon=false title="Parecer do Docente"} Classificou como Projeto , mas as justificativas apresentadas citam requisitos funcionais de execução e conexão, sem articular as características ontológicas do Cap. 1 (resultado único, temporalidade ou restrição de recursos). Pontuação: 0,8 / 1,5. ::: ### 1.2 Alternativas de Trade-off no Triângulo de Ferro (0,5 / 2,0) ::: {.callout-note icon=false title="Resposta Transcrita do Aluno"} > "Reduzir os testes automatizados vai requerer menos do P.O e do Dev que são 'responsáveis', mas diminuirá a chance de encontrar erros, assim como diminuirá o custo de tempo que levaria para realizar os testes e o custo geral. Tudo isso não vale a pena pois a qualidade diminuirá." ::: ::: {.callout-tip icon=false title="Parecer do Docente"} A discente analisou as consequências de cortar testes, mas o comando solicitava expressamente propor duas alternativas de trade-off sem sacrificar qualidade (ex: negociar escopo, estender prazo ou alocar mais recursos). Pontuação: 0,5 / 2,0. ::: ### 1.3 Classificação do Ciclo de Vida (1,0 / 1,5) ::: {.callout-note icon=false title="Resposta Transcrita do Aluno"} > "Seria híbrida, pois considerando o tempo de aula e a duração de cada sprint a cada duas semanas teríamos duas aulas, logo 7 sprints. O ciclo de vida pode ser mais ágil em cada sprint, mas como um todo sendo híbrido." ::: ::: {.callout-tip icon=false title="Parecer do Docente"} Classificou como ciclo Híbrido e articulou a cadência de aulas com as sprints. Faltou aprofundar na resposta à incerteza da IA. Pontuação: 1,0 / 1,5. ::: --- ## Questão 2 — Escopo, EAP e Backlog (2,8 / 5,0 pts) ### 2.1 Estrutura Analítica do Projeto (EAP) e Regra dos 100% (0,75 / 1,5) ::: {.callout-note icon=false title="Resposta Transcrita do Aluno"} > [Diagrama: 3 blocos: autenticação, interface e integração, armazenamento e dashboard com tarefas subordinadas] ::: ::: {.callout-tip icon=false title="Parecer do Docente"} Identificou 3 grandes blocos estruturais no quadro. Contudo, utilizou verbos nas folhas subordinadas e omitiu completamente o texto conceitual explicativo da Regra dos 100% . Pontuação: 0,75 / 1,5. ::: ### 2.2 Detalhamento de Issues e Estimativa Relativa (1,0 / 1,5) ::: {.callout-note icon=false title="Resposta Transcrita do Aluno"} > "Issue 1 (título: autenticação; descrição: cabe ao Dev realizar as seguintes tarefas de decidir a API utilizada e o canal de chat a serem utilizados; estimativa de tempo: 1 semana). Issue 2 (título: interface e integração; descrição: cabe ao Dev fazer a integração com a LLM e em conjunto com P.O testar comandos básicos; estimativa de tempo: 1 semana). A primeira issue leva menos tempo e menos esforço por se tratar de decisão, já a segunda requer trabalho prático que demanda + tempo e esforço." ::: ::: {.callout-tip icon=false title="Parecer do Docente"} Definiu as duas issues e articulou o esforço relativo entre decisão conceitual e implementação prática. Faltou detalhar critérios de aceitação verificáveis. Pontuação: 1,0 / 1,5. ::: ### 2.3 Milestones vs. Sprints no Modelo Ágil / Kanban (1,0 / 2,0) ::: {.callout-note icon=false title="Resposta Transcrita do Aluno"} > "As milestones não substituem sprints, o Kanban pode substituir sprints em cenários onde as tarefas estão devidamente divididas e os prazos bem estabelecidos." ::: ::: {.callout-tip icon=false title="Parecer do Docente"} Acertou ao constatar que milestones não substituem sprints. Na análise do Kanban, a justificativa foi simplista, pois o Kanban sem sprints é recomendado para fluxo contínuo sob demanda e não para projetos com datas fixas de cascata. Pontuação: 1,0 / 2,0. ::: --- ## Questão 3 — Qualidade, CoQ e Definição de Pronto (2,3 / 5,0 pts) ### 3.1 Definição de Pronto (DoD) e Relação com CI/CD (1,2 / 1,5) ::: {.callout-note icon=false title="Resposta Transcrita do Aluno"} > "Não, se os testes de segurança forem omitidos o chat não estará 'pronto', pois as verificações de qualidade serão omitidas. Os testes de segurança ao serem pulados comprometerão a validação de todas as funções fazendo com que os problemas não resolvidos agora aparecerão depois com maior impacto." ::: ::: {.callout-tip icon=false title="Parecer do Docente"} Excelente conclusão de que omitir testes viola o critério de pronto e posterga falhas críticas. Faltou enunciar a definição formal do DoD. Pontuação: 1,2 / 1,5. ::: ### 3.2 Classificação PAF dos Custos da Qualidade (CoQ) (0,5 / 1,5) ::: {.callout-note icon=false title="Resposta Transcrita do Aluno"} > "(a) avaliação, (b) custo de prevenção, (c) falha interna, (d) falha externa. O mais alto seria a falha de segurança, pois a equipe deverá buscar no código todo e encontrar essa falha de segurança, além do tempo gasto corre risco do agente socrático ficar inativo por um tempo." ::: ::: {.callout-tip icon=false title="Parecer do Docente"} Houve inversão dos pares conceituais de CoQ: (a) é Prevenção, (b) é Avaliação, (c) é Falha Externa e (d) é Falha Interna. Pontuou pela justificativa do impacto da falha de segurança. Pontuação: 0,5 / 1,5. ::: ### 3.3 Heurística 1:10:100 e Particularidades de Projetos de IA (0,6 / 2,0) ::: {.callout-note icon=false title="Resposta Transcrita do Aluno"} > "Se os testes de segurança forem realizados corretamente, os impactos por erros/bugs serão menos recorrentes. Ao passo que a falta dos testes aumenta muito a incidência dos erros/bugs. Logo, para garantir verificações de qualidade eles são inegociáveis." ::: ::: {.callout-tip icon=false title="Parecer do Docente"} Defendeu a importância dos testes preventivos, mas omitiu a explicação da regra numérica 1:10:100 e a análise dos limites específicos da heurística em IA (não-determinismo). Pontuação: 0,6 / 2,0. ::: --- ## Questão 4 — Riscos, Segurança de IA e Documentação (3,1 / 5,0 pts) ### 4.1 Risco vs. Problema e Posicionamento na Matriz P×I (1,0 / 1,5) ::: {.callout-note icon=false title="Resposta Transcrita do Aluno"} > "Esse evento era um risco que se tornou um problema na execução do projeto. Pois não é algo que é evitado durante a execução e por falha acaba acontecendo. É baixa a probabilidade de alguém vazar a chave, mas se acontecer pode atrasar o andamento do projeto, não sendo tão crítico." [Matriz marcada no quadrante Probabilidade Baixa × Impacto Médio]. ::: ::: {.callout-tip icon=false title="Parecer do Docente"} Diferenciou risco de problema. Considerou o impacto apenas como 'atraso moderado', subestimando o risco financeiro e de segurança que torna o vazamento de API crítico. Pontuação: 1,0 / 1,5. ::: ### 4.2 Ações Imediatas e Prevenção Permanente de Chaves de API (0,8 / 1,5) ::: {.callout-note icon=false title="Resposta Transcrita do Aluno"} > "Correção do código; Reunião para alinhar o ocorrido; Mudar a chave; Para uma ação preventiva seria alertar todos dessa possibilidade e documentar isso." ::: ::: {.callout-tip icon=false title="Parecer do Docente"} Ações imediatas incluíram rotação da chave. Na ação preventiva, recomendou conscientização e documentação, sem propor medidas técnicas automatizadas (como .gitignore ou scanners de segredos no CI/CD). Pontuação: 0,8 / 1,5. ::: ### 4.3 Modelagem de Riscos de IA e Artefatos de Documentação (ADRs) (1,25 / 2,0) ::: {.callout-note icon=false title="Resposta Transcrita do Aluno"} > "Um risco de entrada seria o prompt injection que é causado por falha na construção da segurança, a probabilidade é média e o impacto é crítico. A mitigação seria melhorar o código para que a segurança seja restaurada. Para um risco de saída como alucinação seria mudar o estilo de resposta do agente e registrar isso nas especificações de apresentação do ReadMe." ::: ::: {.callout-tip icon=false title="Parecer do Docente"} Modelou o risco de entrada e saída. Contudo, recomendou o README em vez do ADR (Architecture Decision Record) formal para documentar decisões técnicas de arquitetura. Pontuação: 1,25 / 2,0. ::: --- ## Questão 5 — Comunicação, Stakeholders e Conflitos (2,2 / 5,0 pts) ### 5.1 Comunicação Síncrona vs. Assíncrona no GitLab (1,1 / 1,5) ::: {.callout-note icon=false title="Resposta Transcrita do Aluno"} > "Na comunicação síncrona semanal (como fazemos no nosso grupo) é possível alinhar melhor as tarefas e concretizar o ponto em que estamos do nosso projeto, além de tirar dúvidas entre si. Já a assíncrona, por mais que tenha cada responsável e prazos o controle é menor se comparado ao síncrono. Logo, o melhor cenário é combinar as reuniões síncronas semanais e as issues e etc pelo git lab também semanalmente." ::: ::: {.callout-tip icon=false title="Parecer do Docente"} Boa comparação prática fundada na experiência da equipe combinando reuniões de alinhamento com issues no GitLab. Pontuação: 1,1 / 1,5. ::: ### 5.2 Matriz Poder × Interesse e Estratégia de Comunicação (0,65 / 1,5) ::: {.callout-note icon=false title="Resposta Transcrita do Aluno"} > "Para o professor que é cliente e patrocinador as reuniões síncronas mensais para mostrar os resultados e progressos são importantes. Elas podem ser feitas por canais de comunicação como o Google Meet." [Diagrama: (1, 2) Manter satisfeito; (3) Gerenciar de perto; (4) Monitorar; (5) Manter informado] ::: ::: {.callout-tip icon=false title="Parecer do Docente"} O professor (2) deve figurar em Gerenciar de perto por deter alto poder e alto interesse, e a coordenação (5) em Manter satisfeito . A frequência mensal proposta para o professor é insuficiente em projeto de 5 sprints. Pontuação: 0,65 / 1,5. ::: ### 5.3 Modos de Resolução de Conflito de Thomas-Kilmann (0,4 / 2,0) ::: {.callout-note icon=false title="Resposta Transcrita do Aluno"} > "Nenhum dos dois cenários apresentados seria o mais adequado, pois ambos os modelos de resposta estão sujeitos a alucinações da I.A. O certo seria uma resposta curta e teórica (treinada) para que evite alucinações" ::: ::: {.callout-tip icon=false title="Parecer do Docente"} A discente analisou o problema de engenharia da resposta curta vs longa, mas não aplicou a grade conceitual dos Modos de Conflito de Thomas-Kilmann solicitada no enunciado. Pontuação: 0,4 / 2,0. ::: --- *Laudo gerado oficialmente pela disciplina Gestão de Projetos de Software (GPS) • CEFET-MG Timóteo*